Active
Project:
Drupal core
Version:
main
Component:
user.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
28 Jul 2021 at 21:28 UTC
Updated:
6 Jun 2024 at 06:37 UTC
Jump to comment: Most recent
only having two status Blocked and Active is confusing and extremely limiting.
Why is a user Active when they have not verified their email?
known
Add more user status and make customizable.
Unverified: user has not verified email; Inactive: user has not logged in, but is verified; Active: email verified and user logged in at least once;
Suspended: a temporary number of days being blocked from access. Banned: mod or admin permanently blocked user. Blocked: an automated system blocked user.
not sure
change interface to include the suggestions above.
not sure
not sure
Comments
Comment #2
cilefen commentedComment #4
aaronmchaleComment #8
dwwI regularly find myself having to add more granular "status" fields to users on various projects, it'd be nice if there was a clean way to do this in core.
For my most recent project, I'm using a state_machine field on user entities. It's already installed as a dependency of commerce, and so far it seems to be allowing the flexibility and power I need. If I run into any troubles with this approach, I'll probably contribute them as fixes upstream, so I imagine this can be a fairly viable recommendation for contrib until we figure out if/how/where to add this functionality to core.
It seemed like trying to use core's content_moderation on user entities was asking for trouble. 😅 But users are just content, so why not? 😂 Curious if anyone's gone down that path.
Thanks,
-Derek
Comment #9
kclarkson commentedIn all the years of using Drupal I had always thought there was module to add more options for user status.
We have a use case where we want users to be archived, where we do not want them to have access to edit their account but we still want to be able to show their profile and the content they created.
It also makes a lot of sense in situations where we need accounts to be confirmed by email.
Comment #10
prashant.cYes, I think we need more granular states.
But at the same time, the statuses 'Active' and 'Blocked' as the main account statuses are good for simplicity. If we need more specific classifications, we could consider separating it with a new field say 'Account State.' This field could include statuses like 'Verified,' 'Unverified,' and 'Banned.'
IMO this approach keeps the primary account statuses straightforward and easy to manage, while also giving the flexibility to handle more detailed user states.
Thank you :)
Comment #11
dwwRe: #10 - indeed, that's definitely how it works with a state_machine field. If we use content_moderation, same story: the “Published” flag is still there as a single bit, but the “moderation state” is a separate, more granular field with (potentially lots) more options. While configuring states, one of the most significant options (in all such cases) is / would be: “Is this state published/active or unpublished/blocked?” (Not literally that text in the UI, but the spirit of it).
Since this issue is back at the top of my tracker, I’ll report that the project using state_machine on user entities I was talking about in #8 has launched and this aspect has been working flawlessly. So I highly endorse that for folks looking for an immediate solution to this in contrib…
Comment #12
prashant.c@dww
Yes definitely, the state_machine module you suggested is extremely good and it looks like it is being actively maintained as well from the very beginning.
Thanks!